Chapter 7
The Language of Architecture
"Architecture begins long before software is written. It begins with the words used to describe it."
Why This Chapter Exists
Software is built twice.
The first construction happens in conversation.
The second happens in code.
Long before the first class is written, developers begin describing systems.
"We need a manager."
"This object owns the data."
"Let's add another component."
"The runtime builds the weapon."
Every architectural decision is first expressed through language.
If that language is inconsistent, the architecture will eventually become inconsistent as well.
The Cube Framework therefore treats terminology as part of its architecture rather than merely its documentation.
Words Shape Design
Developers often believe names exist only to improve readability.
In reality, names influence design itself.
Calling something a "Manager" suggests broad responsibility.
Calling it a "Builder" suggests transformation.
Calling it a "Definition" suggests permanence.
Calling it a "Runtime Object" suggests temporary execution.
Every word establishes expectations.
Architecture either fulfills those expectations...
...or gradually creates confusion.
One Concept, One Name
A common source of architectural drift is inconsistent terminology.
Consider the following examples.
Weapon Data.
Weapon Configuration.
Weapon Descriptor.
Weapon Information.
Weapon Setup.
If all five terms describe the same concept, the architecture becomes difficult to discuss.
Developers begin translating vocabulary instead of solving problems.
The Cube Framework deliberately avoids this.
Every important concept should have one authoritative name.
Every name should describe exactly one concept.
Shared Vocabulary Creates Shared Understanding
Architecture is rarely built by one person forever.
Projects evolve.
Teams grow.
Contributors join.
Documentation expands.
Without a shared vocabulary, every developer constructs a slightly different mental model of the same system.
Over time these differences accumulate.
Shared terminology reduces this risk.
When everyone uses the same language, discussions become shorter.
Design reviews become clearer.
Responsibilities become easier to understand.
Language Outlives Code
Implementations change.
Classes are renamed.
Systems are replaced.
Modules evolve.
Terminology should remain remarkably stable.
Developers should continue speaking about Runtime Assembly even if the implementation changes completely.
They should continue discussing Definitions even if the underlying asset structure evolves.
Good architectural language survives implementation.
The Cost of Ambiguity
Ambiguous terminology creates hidden architectural costs.
Developers hesitate.
Questions become longer.
Documentation contradicts itself.
Code reviews become debates about interpretation instead of design.
These problems rarely originate from poor programming.
They originate from unclear language.
Clarity therefore begins long before implementation.
It begins with definitions.
A Language Worth Protecting
The Cube Framework considers terminology part of its public architecture.
Every new concept deserves careful naming.
Every new name should remain consistent across:
- Documentation
- Source Code
- Diagrams
- Tutorials
- API References
Consistency builds trust.
Trust builds understanding.
Understanding enables extension.
Design Note
Whenever introducing a new architectural term, avoid asking:
"Does this sound good?"
Instead ask:
"Will another developer immediately understand its responsibility?"
Names should reduce interpretation rather than encourage it.
Framework Law VII
Architecture is only as clear as the language used to describe it.
Shared terminology creates shared understanding.
Shared understanding creates maintainable software.
Part I Summary
Part I introduced the architectural foundation of the Cube Framework.
Rather than beginning with implementation, it began with principles.
Definitions.
Runtime.
Operations.
Responsibilities.
Complexity.
Architectural language.
Together, these concepts establish the vocabulary and mental model used throughout the remainder of this handbook.
Every chapter that follows builds upon this foundation.
Revision History
Version 1.0
Initial publication.